As its name implies Domain-Driven-Design is a Software Design led by its Domain. Each business has its own special terms. For example, in the stock market, there are “dealers” and “shares”. In a casino, there are also dealers just as well as on the drug market. Same word, different meaning – it all comes down to the context, the specific domain, a term is used for a Domain-Driven-Design to work properly.

First of all, the language itself is of utmost importance. Working in the same industry, this very specific context, this very specific domain and all its terms, can be different for two (2) departments working for the same company. Yes, even for 2 sub-teams of a team of a department in the same company. This is what Eric Evans calls an “Ubiquitous Language“.

Try to talk with your colleagues and the business people in your area of the company, and try to use and or form the “Ubiquitous Language” together with your colleagues.

Then, as step two, try to use as much of these commonly used terms in your code, and try to make your code tell a story. Don’t use comments, use code as your comment instead, especially for boolean conditions.

For example, try writing:

        Angle angle = new Angle();
        if (angle.isSquare()) {
            // do something
        }

instead of:

        double angle = 90.0d;
        if (angle == 90.0d) {
            // do something
        }

Try to make your code as clear and understandable as possible.
Don’t write it once and never touch it again. Touch it as often as possible, iteratively.

Further reading:
Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
Domain-Driven Design: Tackling Complexity in the Heart of Software
Implementing Domain-Driven Design